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ABSTRACT 


This thesis describes a web-based continuous learning module (CLM) for 
use in introducing members of the Department of the Navy’s acquisition 
community to software reuse in the context of Naval Open Architecture. The CLM 
introduces the student to principles for effective software reuse, explains the 
unique challenges of software reuse, discusses software reuse within the context 
of the Naval Open Architecture under the current Department of Defense and 
DON policy and guidance, provides a strategy for successful software reuse, and 
introduces the student to the Software Hardware Asset Reuse Enterprise 
(SHARE) repository established by the Navy’s Open Architecture (OA) program. 
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I. INTRODUCTION 


A. PROBLEM STATEMENT 


The theory and practice of software reuse continuously evolves, but one 
can ask: What are the factors and principles of successful software reuse? The 
Department of the Navy (DON) needs to leverage the use of software reuse in its 
quest to deliver software-intensive systems on schedule, within budget, and with 
the necessary functionality. 


However, before the DoN can reap the benefits of software reuse, the 
Navy must create, promote and positively reinforce a software engineering reuse 
environment. How does the DON ensure that its investment in reuse will provide 


positive dividends? 


The Program Executive Office for Integrated Warfare Systems (PEO IWS) 
identified considers the reuse of software applications as one of the key enablers 
for Naval Open Architecture to support of the development of National Security 
Systems that are modular, interoperable, and affordable to upgrade!. The 
defense community has long recognized the potential benefits that software 
reuse can generate, as evidenced for instance in the well-known article by Doug 
Mcllroy that appeared in 19682. Today large-scale software reuse across the 
industry remains elusive. Despite many setbacks, software developers now have 
a better understanding of the factors and principles for successful software 
reuse, as evident by an ever growing number of reports of successful reuse 


projects3+. In order to increase the likelihood that the DoN will benefit from 





!'N. Guertin, Presentation to the DOD Open Technology Conference, Arlington, VA, March 
14, 2007. 


2M. D. Mcllroy, “Mass produced software components,” in Naur, P. and Randell, B., eds., 
Report on the NATO Conference on Software Engineering, NATO Scientific Affairs Division, 
Brussels, Belgium, 1968, pp. 138-150. 


3M. L. Griss and A. Wosser, “Making Reuse Work at Hewlett-Packard,” IEEE Software, Jan. 
1995, pp. 105-107. 


1 


software reuse, Navy and Marine Corps acquisition professionals need to learn 
about software reuse principles and practices, in addition to learning about the 


linkage between software reuse and Naval Open Architecture. 


This thesis describes a web-based continuous learning module (CLM) for 
use in introducing members of the Department of the Navy’s acquisition 
community to software reuse in the context of Naval Open Architecture. The CLM 
introduces the student to principles for effective software reuse, explains the 
unique challenges of software reuse and discusses software reuse within the 
context of the Naval Open Architecture under the current Department of Defense 
and DON policy and guidance. The CLM also provides a strategy for successful 
software reuse and introduces the student to the Software Hardware Asset 
Reuse Enterprise (SHARE) repository established by the Navy’s Open 
Architecture (OA) program. 


4 A. Tomer, L. Goldin, T. Kuflik, E. Kimchi, and S. R. Schach, “Evaluating Software Reuse 
Alternatives: A Model and its Application to an Industrial Case Study,” IEEE Transactions on 
Software Engineering, 30, 9 Sept. 2004, pp. 601-612. 


2 


ll. BACKGROUND 


A. INTRODUCTION 


Software reuse promises huge returns in productivity, better quality, anda 
decrease in time to market for products. Software reuse is a quickly developing 
underlying pillar of the Naval Open Architecture Enterprise. 


B. SOFTWARE REUSE 


All types of software-development artifacts (e.g., use cases, requirements, 
designs, architectures, patterns, test cases, code, documentation, etc.) can 
potentially be reused if they are designed for reuse from the start. Hands-on 
experience has led the industry to the belief that substantial reuse can only 
happen in two areas: opportunistic and systematic. George Santayana’s 
statement, “Those who cannot remember the past are condemned to repeat it’, 
may not be completely true. The past can have triumphant moments as well. The 
trick is to be aware of the victorious pieces from the past to draw from for future 
events. This mindset applies to software engineering. Software engineering is an 
expanding field that has changed direction and priorities very rapidly over the last 
decade. Exhaustive studies and numerous projects have produced and positive 
results that are neither repeated nor shared across system development. 


Software reuse has its roots in computer programming, with the 
development of software libraries containing subroutines, functions, and other 
reusable units of software. Today, software reuse includes the spectrum of 
system artifacts, including such things as requirements and software patterns. 


So far in the twenty-first century, the focus has been rapid application 
development, fastest time to market for updates and keeping up with the Internet 
technology wars. The last fifty years have seen tremendous changes in software 
engineering. The late 1990s saw a shift from processes, tools, documentation, 


negotiations and plans to individuals, collaborations, working software, and 
responding to change. The enterprise that can get a product or service to market 
first wins. Organizations have moved away from the traditional waterfall models 
to spiral, evolutionary, or iterative process models. Such models use the project's 
risk to determine how much engineering is enough. Organizations have also 
turned to open source development as another means of speeding up time to 
market and getting expansion ideas for future code capability. This century has 
also seen an exponential increase in the use of software by non-programmers. 
The increased usage has forced programmers to create much better Graphical 
User Interfaces (GUI). This also opened the door to more in-depth studies on 


Human Computer Interaction (HCl). 


Software reuse is a means to achieve improvement in overall software 
production. A high-quality software reuse process can contribute to improved 
productivity, quality, and dependability, in addition to aiding the acquisition 
professional in better managing the schedule, cost, and performance of a 
program or project. An initial investment is necessary, which can be relatively 
large in some cases, to establish a software reuse program. However, that 
investment can pay for itself over time. In short, the development of a reuse 
program and the reuse process employed in that program can help both to 
reduce risk in legacy and new system developments. 


According to Estublier and Vega, “Reuse is not a goal in itself; it aims at 
speeding up and decreasing maintenance cost.”> They also suggest that “a really 
reusable component has a significant cost; therefore, to be cost effective, a 
reusable component must be widely REUSED.”© In some broader definitions, 


reuse is the use of artifacts or components from existing systems to build new 





5 J. Estublier and G. Vega, “Reuse and variability in large scale applications,” in Proceedings 
of the 10th European Software Engineering Conference, ACM, Lisbon, Portugal, Sept. 2005, pp. 
316-325. 


6 J. Estublier and G. Vega, “Reuse and variability in large scale applications,” in Proceedings 
of the 10th European Software Engineering Conference, ACM, Lisbon, Portugal, Sept. 2005, pp. 
316-325. 
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ones in order to achieve the advantages of reuse. The reuse backdrop 
encompasses a range of possible reuse techniques (See Figure 1). Reuse is the 
use of existing software to build new software. Variations in the definitions range 
from adding words like “software knowledge” and expanding the reuse umbrella 
to include all aspects of a software development, such as reusing a particular 


software process. 
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Figure 1. Reuse Backdrop. Adapted from |. Sommerville, Software 
Engineering, Upper Saddle River, NJ: Addison Wesley, 7" ed., 2004. 


The concept behind reuse is clear-cut. Reuse emphasizes strategies, 
techniques and principles that enable developers to create new systems from 
components in repositories. Furthermore, software reuse is of interest to the 
Department of Defense because it is not practical for DoD to develop systems 
from scratch—it is too costly and time-consuming to do so. Today’s acquisition 
environment is one in which legacy systems and components are brought 
together in new developments to meet the needs of the warfigther to achieve 
transformation, that is, rapidly transitioning concepts and technologies to systems 
deployed in the  battlespace. According to a spokesperson from 


ComponentSource, the concept behind software reuse is a simple yet powerful 
one. “Reuse before you buy. Buy before you build. And if you must build anew, 


learn how to share.”7 


Software reuse is divided into two types: opportunistic and systematic. 
Software salvage, euphemistically known as opportunistic reuse, is the 
unplanned reuse of system artifacts not originally designed with reuse in mind. 
In contrast, systematic reuse is deliberate in the sense that the artifacts are 
designed to be reused. The latter is the preferred type of reuse. 


C. OPEN ARCHITECTURE 


PEO-IWS identifies software reuse as one of the key enablers for Naval 
Open Architecture. As of today, large-scale industry-wide software reuse remains 
elusive. Within the DoN many open architectures are coming into existence. The 
issues involve determining the right contract language, obtaining access to reuse 
libraries, and the age-old issues of upgrading legacy systems coupled in software 
and hardware. Issues spill over into every aspect of the software development 
process. 


Open Architecture denotes an architecture whose specifications are 
public. This includes officially approved standards as well as non-standard 
architectures whose specifications are publicly available. The opposite of open is 
closed or proprietary. 


The great advantage of open architectures is that anyone can design add- 
on products for it. By making architecture public, however, a manufacturer allows 
others to duplicate its product. The Navy’s definition of Open Architecture (OA) is 
an enterprise-wide, multifaceted strategy for acquiring and maintaining National 
Security Systems through joint interoperable systems that adapt and exploit 


open-system design principles and architectures. Fundamentals of the OA 





7M. Pepe, “Government Reduce, Reuse, Recycle Code.” CRN 23 July 2001. 
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strategy include increasing opportunities for competition and innovation, enabling 
rapidly fielded and upgradeable systems, and optimizing software asset reuse. 


The Navy and Marine Corps have adopted OA as a way to reduce the 
rising cost and increase the capabilities of Naval warfare systems and platforms. 
Naval Open Architecture (NOA) allows for incorporating more COTS technology 
in warfare systems and enabling reuse of software and related assets. More 
importantly, OA will contribute to greater competition among system developers 
through the use of open standards and standard, published interfaces. 


The definition of OA has to be stated if the Government intends to procure 
a system having open architecture designs and corresponding components. The 
contracting department must have a basis by which to understand the sharing of 
software and proprietary rights. It will also have to make a long list of demands 
on the contractor. As part of this contract process, contractors will be required to 
define, document, and follow an open systems approach for using modular 
design, standards-based interfaces, and widely supported consensus-based 
standards. Contractors will develop, maintain, and use an open system 
management plan to demonstrate compliance. The proposed open system 
management plan will be incorporated into the contract. 


Beyond contractual language, there are standards by which code for 
sharing and reuse should be written. The idea behind standards is really 
facilitating open architecture and fast turn around of a capability. Code should be 
designed using industry-standard formats. Code should develop and maintain an 
architecture that incorporates appropriate considerations for portability, 
maintainability, technology insertion, vendor independence, reusability, 
scalability, interoperability, upgradeability, and long-term supportability. Code 
should be developed through an architecture that is modular and use non- 
proprietary or key Application Programming Interfaces (APIs). Code should be 
documented to describe how the proposed system architecture took into account 
the attempts to use non-proprietary or COTS wherever practicable. Code design 


should try to minimize inter-component dependencies to allow components to be 
decoupled and reused, were appropriate, across various Naval programs and 


platforms. 


Development standards create a problem. The correct way to do business 
is to go with the old military standards. The military standards however are very 
costly for the contractors to produce, causing the contractors to pass on their risk 
to the government in a contractual line item. The government needs contracts 
that can alleviate some of the burden placed on contractors while still holding 
them to some agreed upon standard. 


The Navy should expect to expend resources to upgrade legacy systems 
once the processes for reuse and open architecture achieve a certain level of 
maturity, but the costs of the upgrades will conceivably be offset by the savings 


from software sharing. 


Naval Open Architecture must match or exceed the rapid evolution in 
commercial technology. The delivery of new technologically advanced 
capabilities across the entire family of warfighter systems or platforms must be 
delivered both faster and cheaper if the military is to retain its superior warfighting 
capabilities in the coming years. The current process takes a decade, cost 
billions of dollars and only delivers in some cases minimal improvements in 


warfighting capability. 
D. SOFTWARE, HARDWARE ASSET REUSE ENTERPRISE (SHARE) 


Software, Hardware Asset Reuse Enterprise (SHARE) repository is part of 
the Navy’s Open Architecture (OA) approach. SHARE is a resource in 
implementing NOA that aids in the cataloging and development of open 
components that include reusable software applications. SHARE provides a 
capability to search for, share, manage and maintain reusable assets. SHARE 
has a card catalog and resource library. The card catalog is web-based and 


supports such actions as searching for code and sharing code. The resource 
library currently only contains software for Navy Surface Domain programs. 


E. SUMMARY 


Software reuse has become a hot topic in all aspects of the software 
community. A “software asset” is not simply another term for source code, but 
rather is anything produced during software development and designed for 
reuse. The DoD has seen its value and has incorporated it as part of a new 
strategy to acquire weapon systems. When properly applied, reuse can produce 
benefits, which include increased product quality and decreased product cost 
and schedule. The greatest benefits come from a domain specific approach, 
where a common set of reusable software assets act as a base for similar 
products production. Software reuse has substantial upfront investments, but 
when properly monitored can produce huge dividends. 


The DoN recognizes the need for Open Architecture in system 
development. With an ongoing war and mounting budget constraints, there exists 
a need to produce software for the warfighter in an even more efficient and 
effective manner. The DoD is moving away from each service having its own 
special systems to accomplish missions. In the near future, each service will 
draw from a pool of similar software designs for future capabilities within that 
service. The Navy has delineated a specific set of OA core principles by which to 
operate and drive its new OA endeavors. 


THIS PAGE INTENTIONALLY LEFT BLANK 


lll. WEB-BASED CONTINUOUS LEARNING MODULE (CLM) 


A. INTRODUCTION 


Software Reuse is an underlying pillar of the Naval Open Architecture 
Enterprise. Software reuse blends software and future capability. This approach 
is gaining increasing use within commercial, defense industry and government 
facilities as the most effective way to improve quality reduce time in getting new 
products to the front lines and increase productivity. It is important for Navy and 
Marine Corps acquisition professionals and program managers to understand 
these principles in order to make the correct choices and reap the benefit of 
software application reuse in the Naval Open Architecture. We developed this 
web-based continuous learning module (CLM) to teach DoN personnel about 
software reuse in Naval Open Architecture. The CLM introduces students to the 
principles for effective software reuse, explains the unique challenges of software 
reuse and discusses software reuse within the context of the Naval Open 
Architecture under the current DoD and DON policy and guidance. The module 
also provides a strategy for successful software reuse and introduces students to 
the Software Hardware Asset Reuse Enterprise (SHARE) repository established 
by the Navy’s Open Architecture (OA) program. The CLM contains five modules, 
with periodic review questions through out the course. The CLM also contains an 
end-of-course review and a post-training examination. The average cumulative 
time for course completion is two hours. Upon completion of this module, you will 


receive two Continuous Learning Points (CLP). 
B. MODULE ONE 


The first module discusses all five modules in general. In order to access 
all the features of the CLM, your computer must meet specific system 
requirements and have all the necessary software applications such as Windows 


Media Player and Flash Player. The computer’s monitor requires the appropriate 
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screen settings to ensure all components from the CLM are visible. There will be 
help links embedded in the courseware to assist the user in correcting problems 
associated with viewing the course material. If the student cannot correct the 
problems, they will seek help from a DoD IT professional. There are consistent 


features that are available to you throughout the CLM (See Figure 2). 


There are consistent features that are available to you throughout this course. Review the text by 
each pointer to better understand these features. 


Move your 


The Table of cursor over the 
Contents displays image to display 
<a each lesson’s information 


name. When you about the imaae D 
finish a lesson, 


click the next 
—_ 


Click on the "D” 
link to read a 
detailed 
description of 
the image or 
Flash® movie 


You will be introduced to new 
concepts and terms within the 
module. A hotword is indicated 

- by text that is red and 
underlined. 





Use the Next and 
Back buttons to 
progress forward and 
back through any 
section of the 


V 


Clicking the word will allow you 
to see the definition for that 
term. Try clicking the hotword 
above to see its definition. 





Figure 2. Navigation and Layout 


The rest of the course will contain four lessons: 

e Introduction to Software Reuse 

e Principles of Effective Software Reuse 

e Naval Open Architecture and Software Reuse 


e Implementation Issues 


Each lesson will have its own lesson objectives. Additionally, each module 
contains Knowledge Reviews throughout. These Knowledge Reviews are 
designed to prepare you for the end of module examination. Knowledge reviews 
are not graded, you may take them as many times as you would like. The exams, 
on the other hand, require you to demonstrate mastery of the learning objectives 
covered by its associated topics. The last two module features are the Summary 
slide and Exam. The summary slide reviews the items that you should have 


covered and the exam will cover questions that were presented somewhere in 
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the lesson. To complete this module successfully, you must pass all exams with 
a score of 100%. The CLMs allow for unlimited test attempts until a 100% score 
is obtained. There is no instructor interaction. To receive credit for this module 


you must complete: 


e Each section of the module 
e Each test 
e The end of module survey 


Upon completion of the CLM the student will download a certificate verifying his 


or her completion of the module. 
C. MODULE TWO 


The first lesson of the CLM is Introduction to Software Reuse. The focus 
of this lesson is to present an overview Software Reuse. After successful 
completion of this lesson, students will be able to: 


e Define Software Reuse 
e Describe Types of Software Reuse 
e Describe Benefits and Potential Show Stoppers of Software Reuse 


Software reuse is the process of creating software systems from 
predefined software components. Software reuse is subdivided into four types: 
Opportunistic, Systematic, Domain-Oriented and Strategy Driven. Opportunistic 
Reuse can be thought of as ad hoc or an individual effort where individual effort 
happens by chance. Systematic Reuse is planned or a corporate-level effort 
where corporate level is a repeatable process with supporting infrastructure. 
Domain-oriented Reuse centers around domain analysis, component 
development and component repository support. Strategy Driven focuses more 
on using software from a business prospective to cut cost, improve quality and 


create new business opportunities. 


Software reuse has many benefits. Software reuse can reduce 


development cost, increase dependability of the developed system, and reduce 
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process risks. Software engineers do not have reinvent the wheel each time that 
a new project comes around; instead they can concentrate their efforts on 
problem-solving activities. Component interfaces are more standardized further 
driving down uncertainty and cost. It also adds a degree speed by avoiding 


customized development. 


With any benefits, come potential showstoppers. Software Reuse can turn 
costly if extensive effort is required in adapting the reusable code. Maintaining 
and improving a component library will also incur cost if not done properly. Lack 
of tool support will cause difficultly in searching for the correct components and 
the integration of those components into a heterogeneous component library. 
Specialists tend to want to rewrite components to make them better verses using 
what is in the library. 


D. MODULE THREE 


The second lesson in the CLM discusses Naval Open Architecture and 
Software Reuse. The focus of this lesson is to present an overview of the 
DoD/DON effort in Software Reuse. Students who successfully complete this 


module will be able to: 


e Define Naval Open Architecture 
e Summarize the Software Reuse policies from Department of Defense 


Open architecture is defined as a type of computer or software 


architecture that is considered public. The opposite of closed or proprietary, it 





includes both industry standard and privately designed architectures that are 
made public. It allows users to see the inner workings of architecture, and allows 
for adding, upgrading, and swapping of components. 


The Naval Open Architecture (NOA) is a multi-faceted strategy providing a 
framework for developing joint, interoperable systems that adapt and exploit 
open system design principles and architectures. It is a System Reuse 
framework that includes a set of principles, processes, and best practices. The 
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goals of NOA are to optimize total system performance, reduce difficulties in 
system development and upgrades, minimize total ownership costs and rapidly 
field affordable, interoperable systems. NOA will accomplish its goals by 
creating more opportunities for competition, the use of non-proprietary standards 
for internal interfaces, modular architectures to allow for affordable 
interoperability and to accommodate changing technology and requirements and 
finally through software reuse. Naval Open Architecture is a business process 
renovation, not just a changing software development practices as in Open 
Architecture. NOA emphasizes on the use of business drivers to produce better 


and less expensive software. 


With the onset of the Naval Open Architecture initiative, there must be 
governing policies and procedures. Below is a list of the Software Reuse policies 
from Department of Defense: 


e 12 May 2003, DoD Directive (DoDD) 5000.1, “The Defense Acquisition 
System” 


e 5 Apr 2004, Under Secretary of Defense (Acquisition, Technology & 
Logistics) Memorandum, “Amplifying DoDD 5000.1 Guidance 
Regarding Modular Open Systems Approach (MOSA) Implementation” 


e Assistant Secretary of the Navy (Research, Development & 
Acquisition) (ASN [RD&A]), 5 Aug 2004, OA Policy Statement, “Naval 
Open Architecture Scope and Responsibilities” 


e Deputy Chief of Naval Operations (OPNAV) (Warfare Requirements 
and Program) (N6/N7), 23 Dec 2005, “Requirement for Open 
Architecture (OA) Implementation” 


The above policies direct DoD to implement a Defense Acquisition System that 
will be more Flexible, Responsive, Innovative, Disciplined, and Be Streamlined 


and Effectively Managed. 
E. MODULE FOUR 


The third lesson in the CLM discusses Principles, Thinking, and 


Requirements of Effective Reuse. The focus of this lesson is to present 
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Principles for effective Software Reuse. Students who successfully complete this 
module will be able to: 


e Describe Effective Principles 
e Describe Reuse Thinking 


e Describe Reuse Requirements 


Effective principles in software reuse are necessary. Principles are 
governed through designing code with reuse in mind, which involves designing 
software around good design and existing components. Software components for 
reuse should be independent, reflect stable domain abstractions and provide 
access to state through interface operations. Lastly, successful and safe reuse 
must have a well documented design rationale and design assumptions for both 
the system and the software design. 


Effective principles can only be as effective as the thinking associated 
therein. The key difference between reuse processes and conventional software 
engineering processes is that for reuse, the customer’s requirements are 
modified to take advantage of what is available for reuse. While the customer 
may not get exactly what they want, the software should be available more 


economical and in a shorter time. 


Once the effective principles are institutionalized, concise requirements 
can now be written. Requirements point to the appropriate reusable components. 
Reusable components should be trustworthy and behave as specified in the 
requirements. Components should also have associated documents to help the 
code specialist understand them and adapt them to new application. 


F. MODULE FIVE 


The fourth and final lesson in the CLM discusses Implementing Software 
Reuse. The focus of this lesson is to present ways to implement software reuse. 


Students who successfully complete this module will be able to: 
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e Understand the organizational and technological enablers 
e Describe strategy to implement software reuse 

e Understand the importance of reuse metrics 

e Know how to use the SHARE repository 


The first step in setting up a reuse program is to identify and develop the 
enablers for Software Reuse. Enablers consist of Organizational and 
Technological Enablers. Examples of Organizational enablers are culture, 
structure and polices. Examples of Technological enables are COTS, 


Component-based engineering and domain engineering. 


The second step is to establish a strategy to gain acceptance and 
institutionalization of Software Reuse. The goal is to maximize the benefits of 
software reuse, taking into consideration resources, personnel, activities and 
desired outcomes. An example of a strategy may contain the following or similar 
steps: 

e Initiate reuse program development 

e Define reuse program 

e Establish reuse adoption goals 

e Analyze reuse adoption strategies 

e Develop reuse action plan 


e Implement and monitor reuse program 


In summary, ensure that enablers are supported and that you are 
designing for reuse. Document the software components and collect metrics 
during the projects. There is not a “one size fits all” set of reuse metrics and 


metrics can be misused. 


One of the United States Navy’s initiatives and a resource in implementing 
NOA is the Software, Hardware Asset Reuse Enterprise (SHARE) repository. It is 
part of the Navy’s Open Architecture (OA) approach to developing open, 
component that include reusable software applications as a core principle. 
SHARE provides a capability for discovering, accessing, sharing, managing, and 
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sustaining reusable assets. It has an asset library and a card catalog. Currently, 
it contains only one type of software specific to surface ships. Please see 


Appendix A for full details on the SHARE repository and its way ahead. 


IV. RECOMMENDATIONS AND CONCLUSIONS 


A. THE FUTURE 


In 2006 several policies and procedures were promulgated directing 
actions be taken to move the DON in the direction of an open architecture culture, 
but there is no over-whelming evidence that the policies have been embodied or 
taken hold in the development of Navy systems. This thesis describes a web- 
based continuous learning module (CLM) for use in introducing members of the 
Department of the Navy’s acquisition community to software reuse in the context 
of Naval Open Architecture. It is likely that a portfolio of continuous learning 
modules will be developed by the DoN, incorporating the CLM described here, 
the Navy Reuse Enterprise. 


One area of future work is to investigate how to promote the 
organizational acceptance of software reuse. However, in the near term, the CLM 
needs to be vetted by the Navy Program Executive Office for Open Architecture. 
In addition, the Defense Acquisition University, which will host the CLM, needs to 
verify module content, finalize the layout of the module, and update the DAU 
catalog of online courses to reflect the availability of the module. 


Each of the sub modules of the CLM needs to be expanded in terms of 
depth of coverage. It should also capture any results from real-world successes 


and failures regarding NOA. 


THIS PAGE INTENTIONALLY LEFT BLANK 
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Introduction 

The purpose of this paper is to lay the foundation for the Naval Postgraduate 
School SHARE component specification and ontology research project funded by 
Program Executive Officer, Integrated Warfare Systems (PEO-IWS). It is 
intended for use as a communication vehicle between the stakeholders and 
project performers to ensure congruence of goals and to validate requirements. 
First, we characterize the problem domain by describing the Software, Hardware 
Asset Reuse Enterprise (SHARE) repository, its contents and its unique 
attributes. Based on this investigation, we then provide specific 
recommendations for both near term and long term improvements. The near 
term suggestions are essentially “low hanging fruit’, or ideas for quick 
improvements that can be implemented in a relatively short time frame. The long 
term improvements are associated with the benefits that can be realized once the 
component specification and ontology have been implemented. Finally, we 
outline requirements for the component specification in terms of its intended use 
within SHARE. 


Background 

In August 2006, PEO-IWS established the SHARE repository to make available 
combat system software and related assets to current and potential Navy 
contractors [5]. SHARE is one piece of the Navy’s Open Architecture (OA) 
approach to developing modular, open systems [6], which includes reusable 
software applications as a core principle. 


PEO IWS is currently seeking ways to improve and mature the capability 
provided by SHARE. Among other initiatives, two related research projects are 
in progress at NPS. _ The first, and the topic of this paper, will produce a 
component specification framework and ontology for use in SHARE. The 
component specification is essentially a model of the assets incorporated into the 
repository, which will enable robust search and discovery capabilities, asset 
submission assistance, and other repository functions. The ontology is a 
framework for the relationships between components, providing contextual 
meaning to asset descriptions. The second project will develop a prototype of a 
semantically-based requirements search engine (RESEARCH) with the tools 
necessary to convert documents into semantically-based formal representations 
of requirements [4]. 
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What is SHARE? 

SHARE provides a capability for discovering, accessing, sharing, managing, and 
sustaining reusable assets for the Navy Surface Domain’s programs [1]. SHARE 
consists of an asset library and a card catalog. The asset library is a collection of 
combat systems software and supporting artifacts. The card catalog is a web- 
based interface that facilitates user insight into the contents of SHARE and 
supports user functions including account registry, asset search and discovery, 
asset submission assistance, and asset retrieval requests. 


The SHARE asset library is separate from the card catalog for two primary 
reasons. First, the majority of the contents of SHARE is classified material and 
therefore must be kept in a SECRET or higher container. Second, the process 
for retrieving assets from SHARE includes necessary steps for addressing the 
data rights associated with each component. For most of the components, a 
license agreement and Non-Disclosure Agreement are required before an asset 
can be issued. Due to these restrictions, the web interface and the actual assets 
are physically separated. 


The search and discovery process in SHARE is conducted either through 
individual navigation of the list of assets in the catalog (see Appendix B), or by 
keyword search of more detailed descriptions. From the catalog list, a user can 
select an asset for the detailed description, which consists of identity, description 
and usage information if they are available. The identity information includes 
asset point of contact, ID, name, version, type, editor and update information. 
The asset description includes a free-text overview, classification level, export 
control and distribution statements, current state of the asset, artifact types and 
usage instructions. Usage information includes user agreement, subscriber, and 
user information. 


The metadata for assets is collected during the asset submission process via an 
excel spreadsheet available on the SHARE user interface (see Appendix A). 
Submitters download the spreadsheet and then email the completed form to the 
SHARE helpdesk. This information includes not only contributor and asset 
descriptions, but also begins to address the domain specific information by 
identifying the asset’s tie to the generic architecture provided by the Surface 
Navy OA Warfare Systems Architecture Element Level Decomposition. 


Assets are requested from SHARE using an online interactive questionnaire. 
The user is asked several basic questions, such as which assets are being 
requested, the justification, and delivery information. The tool then prepares the 
necessary documents, including non-disclosure and license agreements, and 
provides them, along with instructions for printing and submission, to the user. 
Once the documents have been mailed in to the SHARE administrators, the user 
can track the status of the request online through the SHARE interface. 
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The SHARE user interface also includes some administrative information such as 
points of contact for the SHARE program, the list of registered users, a document 
library, and a calendar. There is also a place where feedback can be posted. 
However, this feature has not yet been utilized. 


What is in SHARE? 

The contents of SHARE are listed in Appendix B. Currently, SHARE includes the 
software and supporting documentation for an Aegis Baseline (7.1.1.1), the 
DDG1000 Total Ship Computing Environmental Infrastructure (TSCEI), and Ship 
Self Defense System (SSDS) Mk 2 Mod 1. For the Aegis baseline, the source 
code applications for all major subsystems with build files are included in the 
repository, as well as prime item development specifications (PIDS), computer 
program requirements specifications, interface design specifications (IDS), and 
user manuals. The TSCEI assets include both documentation and source code. 
SSDS _ submissions include the System/Subsystem Specifications (SSS), 
Software Requirements Specifications, (SRS) and source code for major 
subsystems. Additionally, the repository includes the Littoral Combat System 
(LCS) Open Data Model, which provides the mission architecture for LCS [2]. 


What makes SHARE Unique? 

Several aspects of the SHARE repository make it unique when compared to any 
number of existing software repositories such as SourceForge [7] or Koders [8]. 
The first unique attribute is that the current artifacts incorporated in the database 
are very similar. They are each large subsystems of combat systems for Navy 
surface platforms. They have a similar level of granularity (very large and 
complex), and they are all traceable to a subset of the Surface Navy OA Warfare 
Systems Architecture Element Level Decomposition. 


While this observation seems to point to trivial solutions for the repository, 
consideration of the future of the repository yields a different perspective. A 
primary realization is that the number of artifacts in the library will continue to 
grow. At some point, the number of items alone will render the search and 
discovery process difficult if not aided by visualization tools and robust search 
engines. Furthermore, if the goal of enterprise wide repository-enabled software 
reuse is to be realized, it is likely that the artifact characteristics will evolve over 
time. As Open Architecture becomes a standard development approach, more 
modular systems will be introduced. Once that occurs, it will be advantageous to 
be able to identify and retrieve modules rather than subsystems. In other words, 
active repository use is likely to stimulate more granular activity. Additionally, to 
enable enterprise-level asset sharing, the repository must support the expression 
of component capability and utility in a meaningful way across domains. It is also 
important to note that SHARE is intended include hardware artifacts, although 
these types of items are not currently included in the card catalog. In summary, it 


23 


is expected that over time the artifacts in SHARE will both become more 
heterogeneous, as well as be required to hold meaning among other more 
heterogeneous artifacts. 


Another unique characteristic of SHARE is that there is no immediate access to 
assets in the repository. Due to the classification and data rights issues, we must 
distinctly separate the tools used for search and discovery from the components 
themselves. We cannot insist, for example, that the component specification 
become part of the component as a wrapper and expect the tools to interface 
with it directly. These classification and data rights issues force another 
important consideration. Since one of the most cumbersome processes 
identified for SHARE is the navigation of access authority and permissions for 
component retrieval, solutions aimed towards improving the usability of the 
repository should incorporate mechanisms for aiding in this process. 


An additional distinguishing characteristic of SHARE is the part is plays in the 
context of the Navy enterprise. Each of the items in SHARE represent “product 
lines” in the surface domain, and the surface domain is a part of the larger Navy 
enterprise. This framework provides contextual meaning to the assets and also 
becomes the driving force for the desired relevance of tools developed for 
SHARE. Where possible, it is desirable to incorporate the domain information 
related to an asset to maximize its contextual meaning. Additionally, as tools are 
designed, developers should consider their potential use in the larger enterprise 
domain. 


Recommendations for near term improvement 

Throughout this initial research of the SHARE repository, we have identified 
several relatively uncomplicated improvements. These improvements can be 
implemented with the repository in its current state, before any fundamental 
framework is put in place. We offer these suggestions for consideration by 
SHARE leadership to enable near term enhancement of the capability. These 
recommendations include improved use of the metadata, increased web-site 
functionality, and SHARE education. 


The current metadata collected for assets submitted in SHARE includes a free 
text overview of the asset. These descriptions are currently the best tool that 
users have to determine if the asset being considered is going to be valuable for 
them to retrieve. However, these descriptions vary greatly in the information 
provided. On one end of the spectrum, the descriptions provide an overview of 
what the component does in the system as well as information to aid in its use. 
On the other end, very little additional information is provided. In some cases, 
the acronyms that are listed in the card catalog are simply repeated. Without a 
better description, the user must already know a lot about the asset in order to 
decide if it will be useful to them. 
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Descriptions should be written with the assumption that the user does not already 
know what item(s) they are seeking. This may be a difficult perspective for 
program developers to take when writing summaries of their systems. Possibly, 
a template should be provided for the types of information required for a 
description in order to ensure that the appropriate level of detail is included. This 
description should cover what the component does, its contribution to the overall 
functionality of a system, and examples of how the component has been used, 
both in the initial system and as a reused item. Another useful item for searchers 
less knowledgeable about the various combat systems is an acronym list. 


Several features that are popular in commercial search and discovery web 
interfaces such as Amazon, Google, or Netflix may also be implemented in 
SHARE to improve the utility of the repository. Customer reviews, frequently 
asked questions, and tools for visualization are integral sources of information in 
these web sites that could be useful in the SHARE environment as well. 


The Amazon model for customer reviews could be beneficial to repository users 
who have identified an item that looks interesting. Amazon posts the customer 
ratings, a numeric assignment of quality, and also enables written feedback from 
the customer. For SHARE, this feedback could be tailored to answer specific 
questions that users would find useful. Customer feedback would include the 
quality assessment of the items, a description of how the customer used the 
component, and lessons learned regarding the item’s use. As in Amazon, the 
SHARE tool could be set up to automatically distribute periodic emails requesting 
customers to review items that they have retrieved. 


Information visualization aids can help people quickly identify the items of interest 
to them. A commonly used feature in commercial sites is the “People who 
bought this, also bought...” feature. This quickly points users to items they may 
not have been aware of, but may be relevant in solving their problem. Netflix 
allows you to view the details about a video in a window that pops up 
automatically when you move the cursor over a movie cover graphic. This 
feature may be helpful in navigating SHARE by allowing the user to view the 
detailed descriptions of components without having to click on them and wait for 
the information to open. Another improvement that may help provide contextual 
significance to repository items makes use of the reference architecture 
information. Currently, the link between the component and the SNOA reference 
architecture is collected at the time of asset submission. It may be a simple 
implementation to build a search interface based on this mapping. As a search 
option, the user could choose to display the architecture framework, and then 
navigate to the components in the repository by clicking on the individual module 
entities. 


A Question and Answer (Q&A) blog could be tied to each the repository assets. 
Users interested in an asset would post questions that they have about 
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components that seem initially attractive, and asset owners post answers. Over 
time, the Frequently Asked Questions (FAQ) can be collected for quick 
reference. Also, FAQ’s may reveal a lack of critical information in a component 
description, which can then be worked into the component metadata. The Q&A 
blogs themselves may provide valuable information to users as well. The same 
concept can also be applied to the SHARE repository overall. 


Our final recommended near term improvement is less a technical solution than it 
is a cultural solution. One of the reasons that existing examples of reuse are 
successful is that people understand what they are reusing. We reuse our own 
code, data structures, and design patterns because we already know them and 
understand what they can do for us. To that end, education is critical. Before 
beginning a browse or search, people should understand in general what kind of 
information is available and how it can be used. This can be presented as a brief 
write-up (similar to portions of this paper) or as a simple interactive tutorial. Real 
examples of uses of SHARE would be valuable material to potential SHARE 
users as well and should be included in the information provided. 


The Long Term Vision 

The goal of this research is to improve the development and use of software 
repositories by developing a component specification designed for use in model- 
based applications that greatly improve the effectiveness of a software 
repository. We will develop a specification framework which includes a model of 
the components in the repository as well as the relationships that provide 
contextual meaning. The component models will be based on the behavior of the 
component as well as examples of its uses, both within the original system and in 
any situations where the component has been reused. The relationships may be 
between components within the repository, between the components and a 
reference or domain architecture, the component’s place in the software life cycle 
and other relational information that will aid users in understanding the context of 
the component. 


This framework will enable tools to be developed that will maximize the utility of 
the reuse repository. Two different types of tools have been identified that will be 
necessary to make full use of the framework. The search and discovery tools are 
aimed towards using the information captured in the framework to assist the user 
in identifying and retrieving useful items from the repository. In general, it is 
advantageous to provide multiple ways to search for relevant items so that users 
can investigate the options differently depending on their background and current 
needs. We envision both advanced visualization tools, such as a fish-eye graph, 
to aid in this process as well as tools that enable searching from available 
documentation (such as RESEARCH). The second type of tool needed is tools 
aimed at assisting component developers by minimize the overhead of creating 
the component model and inserting it into the repository. One example is a 
specification-building tool with a wizard-type interface that will assist the 
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developer in creating the component specification as the component is 
developed. Additionally, a tool is necessary for assistance at repository- 
submission time to help the submitter integrate the component into the repository 
by building the desired relationships. 


The component specification framework will incorporate all of the information that 
is collected through the existing efforts to collect SHARE metadata. This 
includes both the information collected through the current excel sheet, as well 
as any of the short term improvements implemented in the interim. 


To support the continued and evolutionary use of the specification framework, 
consideration throughout development of the specification framework will be 
given to potentially changing aspects of SHARE as well as additional candidate 
repositories. As discussed previously, it is likely that the items placed in SHARE 
will evolve over time, from large subsystems to more granular modules. The 
component specification should be able to support this evolution of the contents. 
The framework will also be developed to support multiple repositories. While 
portions of the framework will contain domain specific information, the structure 
and non-domain specific portions should be easily portable to other repositories, 
along with a systematic approach to completing the domain relevant portion. 
Particular attention will be paid to existing DoD and other software repositories, 
especially those under the umbrella of the Navy OA domains such as the PEO 
C4l Net-centric Enterprise Solutions for Interoperability (NESI) repository. The 
specification framework should also support the integration of these repositories 
as intended by OA leadership. 


Finally, it will be important to integrate the technical solutions provided by this 
work into the larger effort to improve software reuse within the Navy/DoD. 
Education, motivation and rewards are needed in order to stimulate the reuse 
cycle. A structured, planned and effective education campaign for these 
technical solutions as well as the entire domain repository effort is needed. 


Requirements for component specification 

Based on the initial investigation into SHARE as described in previous sections, 
the requirements listed here for the component specification framework are 
necessary to provide a solution relevant to the SHARE repository. These items 
will be considered throughout the framework development. 


1. Improved search and discovery capability - The central focus of the 
specification framework is to facilitate the search and discovery process 
for a repository. This includes not only ease of navigation through the 
available components, but also completeness of the information. The goal 
is to educate the user about the candidate components thoroughly enough 
that the user knows what it is they are retrieving prior to going through that 
process. 
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2. Minimize overhead for component submission — Adding this capability to 
the repository will come with tradeoffs. Items must conform to the 
framework in order to be entered into the repository. The overhead to the 
asset submitters should be minimized as much as possible to avoid disuse 
due to unacceptable levels of difficulty. The specification framework will 
support tools to aid the development of the component specification for an 
asset and to assist integration into the repository. 


3. Support multiple user perspectives — The component specification will 
incorporate multiple views for aiding users to reason about which 
components to retrieve. These perspectives include, but are not limited 
to: 

a. Domain specific reference architecture - Where possible, it is 
desirable to incorporate the available system domain information 
related to an asset to maximize its contextual meaning. This may 
be pre-existing in the form of a reference architecture or some other 
materials. 

b. Examples of previous uses — Examples of the components 
previous uses should be incorporated into the framework. This 
includes the component's use in the original system as well as any 
available examples of its reuse in later systems. Both successful 
and non-successful reuse examples can be included. 

c. Intra-repository component relationships — The relationships of the 
components in the repository to each other is also a useful view. 
Items that have been used in the same system or used to perform 
similar functions in different systems can be grouped together. 
Additionally, the threads of components that have been reused and 
reinserted back into the repository as part of a new system should 
be traceable. 

d. Life cycle activity information — Information about the life cycle 
phase or activity that the artifact is intended to support is useful as 
well. For example, a user may wish to search for all requirements 
documentation for systems that perform similar functions to their 
intended new system as a useful reference. 


4. Support for security requirements — Due to the classified nature of the 
assets in SHARE, the interface for search and retrieval must be kept 
separate from the assets themselves. Therefore, the specification model 
must support this constraint of separate locations. Additionally, the 
metadata of classified elements must be constrained to unclassified 
material, and possibly include pointers to classified descriptions. 


5. Support for legal concerns — As discussed in the previous sections, one of 
the primary difficulties specific to SHARE is the navigation of access 
authority and permissions for component retrieval. Any solution provided 
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must take into account these constraints and should incorporate 
mechanisms for aiding in this process wherever possible. 


6. Extensible to other domains — Since SHARE is part of a greater effort to 
improve software reuse across the DoD, the component specification 
framework should support this goal. To that end, the framework should be 
extensible to the other domains under the Navy OA construct and will 
support the integration of these capabilities. Additionally, as supporting 
tools are designed, developers should consider their potential use in the 
larger enterprise. 


7. Scalable for repository evolution — The specification framework should 
support the evolution of the repository, both from the perspective of the 
expected growth in the number of components contained as well as the 
progression towards less homogenous contents (smaller modules vs. 
large subsystems, various asset types — design artifacts, documentation, 
etc.). Additionally, the models should be capable of representing 
hardware artifacts that may be included as assets in the repository in the 
future. 


8. Use of de facto standards — Wherever possible, implementation of the 
component specification framework will employ de facto standards such 
as the Unified Modeling Language (UML), Extensible Markup Language 
(XML), or others in order to promote broader applicability of existing tools 
as well as open an unbiased competition for tools to be developed. 


Future Work 

This paper is the first in a series of intermediate products related to the 
development of the component specification and ontology. Future writings will 
cover the results from an ongoing survey of SHARE users and other feedback 
that has been collected, case studies outlining success and failure stories, and 
intermediate deliverables supporting the larger task. Near term research 
activities will be focused on existing research and practical applications of 
repository submission procedures, repository management tools, component 
specification, and model driven software development (particularly, what models 
are used during various phases of software development) to determine if there 
are existing solutions that will be relevant in accomplishing the goals of the 
project. 
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Appendix — SHARE Asset Contribution Form 


SHARE Asset Contribution v6 


Complete 
HelpDesk@Nice-Help.net, 
melody.belcher@navy.mi, 
Items with 


Contributor: 


Government Major Program 
Manager (MPM): 


MPM Alternate: 


Rationale for Contribution: 
Impacts: 


Asset; 








the yellow areas below, and 


return to: 
with cc: to 


and _ gregory.hartwig@navy.mil 
ray-fill labels will not be published 


Asset Name: 
Asset Description: 
Request Date: 
Name: 


Phone: 


E-Mail ID: 
Organization: 


Mailing Address: 
Program Title: 
Name: 

Phone: 


E-Mail ID: 
Organization + Code: 


Approval: 
Name: 
Phone: 


E-Mail ID: 
Organization + Code: 


Asset Type: 


Tactical Application 


SHARE 


(assigned by Help Desk) 


Sub-Type: 


System 

Application Program 
Package 

System Service 


Control Number: 


Populate one selection below with a description 
of the type of asset 
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Component(s) 

Library 

Module/Code Fragment 

Database / Data Files 
Development Support Framework 

Tools / Utilities 

Test Tools/ Environments 







































Non-code Enterprise Framework 


Data Architecture 
Pattern / Design / 
Algorithm 


Standard / Interface / API 
New, Modified, or Linked: — : 
Dependencies on other 
assets, COTS, etc. 

Version: 

Description: 

Date of Asset: 

Target OS: 

Acquisition or Final? 

Test Level: 

Certification Level: 

OACE Level (self 
assessment): 

OAAT Level (self 
assessment): 

Complete? 

Buildable? 

Planned Updates: 

Usage Instructions: 


Types of artifacts included within the asset: 
Included? (Y/N) ‘ormat (e.g., DOORS, MS-Word, etc.) 





Requirements: Requirements 

Specification: 
Requirements Database: 
Design: Design Models 


Design Documents: 
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Patterns: 

Algorithms: 

White Papers: 

Data Models: 

Simulation Models: 

Code: Source Code: 
Compiled Libraries: 

Executable Programs: 

Test: Test Plan: 
Test Procedures: 

Test Results: 

Test Tools/Scripts: 

Test Source Data Files: 

Test Truth Data: 

Simulators: 

Interface: IRSs/IDDs 
IDSs 

APIs 

Architecture: Architecture Model: 
Architecture Document: 

Supporting Artifacts: User Documentation: 
Training Documentation: 


Build Scripts/Instructions: 
Other: 
Software Programming language and Operating System(s) Supported 
Pgm Language(s): 
Run time Environment(s): 
Media Description: Security Classification: 
Program's Security 
Classification Guide ID#: 


Has MPM pre-approved 
classification release 
authority? 

Media Format: 

Number of Files: 
Structure of Files: 
Total Data Size: 
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Architectural Elements (chec 
all that apply): 





Microsoft 
PowerPoint Slide 





Element 





Intelligence 
Track Management 
Common C2 Services 
Operational C2 
Tactical C2 

Mission Planning 
Resource Management 
NTM Tasking/Status 





Local & Offboard Sensor 
Control 


Sensor Adaptation 
Sensor 

Sensor Stimulation / 
Simulation 
Communications Control 
Communications 
Adaptation 
Communications Devices 
EXCOMM Simulation / 
Stimulation 


Off-board Organic Vehicle 
Control 


Off-board Organic Vehicle 
Adapation 


Off-board Organic Vehicle 





Applic.? (Y or blank) 


Notes 
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Vehicle Simulation / 
Stimulation 





Weapon Simulation / 

Stimulation 

Specialized Trainer 

Ship Control 

Computing Hardware 

Engineering / Damage 

Control 

Readiness / Support 

Adaptation 

Training Control 

Training Assessment 

Training Dev. Env. 

Readiness / Support 
Distribution Statement: 
Data Rights Markings: 
Commercial Software: 
Special Licenses: 
Open Source Software 
Licenses: 
Data Rights Assertions: 
Any Additional Information: 
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Appendix — SHARE Contents (as of 07 Oct 07) 


































































































Name State Type POC Version 
AEGIS 

A-spec: WS-21200/5 SCN 1 Available Documentation Andy Li 7.1.1.1 
B1-specs: ACTS WS-3341 7/2 Available Documentation Andy Li ZAAA 
B1-specs: ADS WS-10666/4 Available Documentation Andy Li 7.1.1.1 
B1-specs: C&D WS-21208/6 Available Documentation Andy Li LAA 
B1-specs: FCS WS-10521/7 Available Documentation Andy Li 7.1.1.1 
B1-specs: ORTS WS-10523/10 Available Documentation Andy Li 7.1.1.1 
Bi-specs: SPY WS-10520/10 Available Documentation Andy Li 7.1.1.1 
Bi-specs: WCS WS-10522/9 Available Documentation Andy Li 7.1.1.1 
B5-specs: TCP WS-33419/2A 

VOL 1-2 Available Documentation Andy Li 7114 
B5-specs: ADS WS-21366/4A 

VOL 1-41 Available Documentation Andy Li 7.1.1.1 
B5-specs: C&D WS-21240/4A 

VOL 1-28 Available Documentation Andy Li 7.1.1.1 
B5-specs: FCS WS-10557/12A Available Documentation Andy Li 7.1.1.1 
B5-specs: ORTS WS-21234/6A Available Documentation Andy Li 7.1.1.1 
B5-specs: SPY WS-10554/16A 

VOL 1-3 Available Documentation Andy Li 7.1.1.1 
B5-specs: WCS WS-10555/17A 

VOL 1-6 Available Documentation Andy Li 7.1.1.1 
IDS-specs: NAV/AWS  S9427- 7.1.1.1 (31 
AN-IDS-020/WSN-7 Available Documentation Andy Li July 1997) 
IDS-specs: WCS/SPY  WS- 

19632/10A Available Documentation Andy Li 7.1.1.1 
IDS-specs: SPY/SPY SIG PRO 

WS-19634/8A Available Documentation Andy Li 7.1.1.1 
IDS-specs: FCS/FCS DCC WS- 

19640/4A Available Documentation Andy Li 7.1.1.1 
IDS-specs: ORTS/WCS  WS- 

19644/10A VOL 1-2 Available Documentation Andy Li 7.1.1.1 
IDS-specs: ORTS/SPY 

19646/12A Available Documentation Andy Li 7.1.1.1 
IDS-specs: WCS/LAMPS WS- 7.1.1.1. (01 
19657/1 Available Documentation Andy Li Mar 2000) 
IDS-specs: ACTS/SPY WS- 

19681/8A Available Documentation Andy Li 7.1.1.1 
IDS-specs: ACTS/WCS_ WS- 

19682/10A Available Documentation Andy Li 7.1.1.1 
IDS-specs: ADS/ORTS WS- 

21267/2A VOL 1-2 Available Documentation Andy Li 7.1.1.1 
IDS-specs: ADS/C&D WS- 

21272/2A VOL 1-2 Available Documentation Andy Li 7.1.1.1 
IDS-specs: ORTS/ACTS WS- 

21278/2A Available Documentation Andy Li 7.1.1.1 
IDS-specs: ADS/ACTS WS- 

21286/2A Available Documentation Andy Li 7.1.1.1 
IDS-specs: ORTS/SCA  WS- 

21287/1A Available Documentation Andy Li 7.1.1.1 
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IDS-specs: _ACEG/AP WS- 

21288A PT 1-5 Available Documentation Andy Li 7.1.1.1 
IDS-specs: _AP/AOCD  WS- 

21290/1A Available Documentation Andy Li 7.1.1.1 
IDS-specs: SPY/C&D  WS- 

21327/8A Available Documentation Andy Li 7.1.1.1 
IDS-specs: C&D/WCS WS- 

21328/7A VOL 1-2 Available Documentation Andy Li 7144 
IDS-specs: ORTS/C&D WS- 

21329/6A Available Documentation Andy Li 7.1.1.1 
IDS-specs: ACTS/C&D 21338/7A 

VOL 1-2 Available Documentation Andy Li 7.1.1.1 
S/W: Aegis C&D source code Available Application Andy Li 7.1.1.1 
S/W Aegis FCS source code Available Application Andy Li 7.1.1.1 
S/W Aegis WCS source code Available Application Andy Li 7.1.1.1 
S/W Aegis SPY source code Available Application Andy Li 7.1.1.1 
Aegis Quick Reference Guides 

(QRGs) Available Documentation Andy Li 7.1.1.1 
Aegis Interface Design 

Specifications (IDSs) Available Documentation Andy Li 7.1.1.1 
Aegis Interface Design Specs / 

ACD-9072_3 Available Documentation Andy Li 7.1.1.1 
Aegis Interface Design Specs / 

WS-10512-2A Available Documentation Andy Li 7.1.1.1 
Aegis Reusable Components 

(ARC) User Manuals Available Documentation Andy Li 7.1.1.1 
S/W: Aegis C&D_ build/support 

files Available Code Andy Li 7.1.1.1 
S/W: Aegis Reusable 

Components (ARC) Available System Service Andy Li 7.1.1.1 
DDG 1000 

TSCEI 4.1 Documentation Acquisition | Documentation Tom Kostyo 4.1 
TSCEI 4.1 Source Code Acquisition | Application Tom Kostyo 4.1 
TSCEI 4.2.2 Documentation Acquisition | Documentation Tom Kostyo 4.2 
LCS 

LCS Data Model 2006-11-22 Acquisition | Architecture/Design Belcher_MelodyS 11/22/2006 
LCS Open Data Model Package 

- 5/22/2007 Acquisition | Architecture/Design | NA 3/20/2007 
SSDS 

SSS: SSDS MK 2 

System/Subsystem Specification | Available Documentation Andy Li MK 2 Mod 1 
SRS: Display Services Available Documentation Andy Li MK 2 Mod 1 
SRS: Human Machine Interface Available Documentation Andy Li MK 2 Mod 1 
SRS: Infrastructure Services (IS) | Available Documentation Andy Li MK 2 Mod 1 
SRS: Tactical Operations (TO) Available Documentation Andy Li MK 2 Mod 1 
S/W: Tactical Operations 

Function Available Application Andy Li MK 2 Mod 1 
S/W: OL Available Application Andy Li MK 2 MOD 1 
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APPENDIX B—- SOFTWARE REUSE IN THE NAVAL OPEN 
ARCHITECTURE 


. 


Software Reuse in the Naval 
Open Architecture 


Continuous Leaming Module (CLM) 


MODULE 1 
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Monitor Screen Resolution 


Flash Pl 


Window Media Plaver 


Accessibility 


Additional Support 





40 


odule Objectives 


dule consists ur lessons. Click each topic for rc 


information on that section of the module 


Introduction to Software Reuse 
Principles of Effective Software Reuse 
Naval Open Architecture and Software Reuse 


Implementation Issues 


pomp letion Criteria 


This module contains Knowledge Reviews throughout. These Knowledge 
Reviews are designed to prepare y ou for the endl of m le exaenimation, Th 
not graded, you may take dvem as ex nes as you would like 


ey are 


5 
Test Requireme 
The cxane requir mut t 


demonstrate mastery of the 


reeave credit fer this module 


UU mast ¢ anptete 

bjectives cov . 
learrung objectives cover 1. Eacks section of the modul ¢ 
associated topics. To complete 


ms 2. Eacks test aed assignenent 
thas anodule successfully, you 
“ wither the ule 

test pass all exanes with a score 

of 100% 3. The <nd of snodule survey 


Upon completion : 


Continweus learning modul es 
you will be abilc to 


allow for urbinated test atten 


ertificate ver: fy 
uedil 100% is reached, There is er a 


<ompletion of this module 
f instructor untcracton 
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Knowledge Review 


son of the module 

will contain questions 
Note: These quest 
nol assigned any pom vi 
and should not be confused 
with Exam questions which 

ec pl 
credit for the courme 
T} K I Rewiew 


1? 
pical 


avigati 1 Layout 


There are consastent features that are available to you throughout thr 
he text by cach poimter to better understand these feature 


ORR ER NN me URE Sm pr. PR! Pen rey 
eel ore be bec ceed eee ler cewe 


te sabre of 
Cpenees Renee 


ont ames 
wee We pe 


to mow 
emer 


wt de Vee we ore 
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“s 


In this module, you learned: 


ummary 


* System Requirements 
* Module Objectives 
* Completion Criteria 


¢ Navigation and Layout 


A CO) B) Gt B Sap 
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Software Reave ls 


Architect 


SSO) yeah vos 


* The focus of this modulc is to present an 
overview of Software Reuse 
* Students who successfully complete this 
naceretttemnal |Moremele) (em ce) 
Define Software Reuse 
Describe Types of Software Reuse 
Describe Benefits and Potential Show Stoppers in 


Software Reuse 





44 


What is Software Reuse? 


: reuse ts the process whereby an 
organizat defines a set of systematic operating 

© specify, produce, classify, retrieve, and 
facts for the purpose of using them 
Mili et.al. 2002) 


¢ Software 


adapt soltware art 
in its development activities 


The use of an asset in the solution of different 


problems 
S Std 1517-1999. EEF Standard for 
Software Life Cyck 


Information Technology 
lectrical 


QD eres FP 20s Dan 
FrocesseF—Neise [Toc 
and Electronics Engine 


} 
3 


Vpes of Software Reuse 


® Opportunistic Reuse (Salvage) 


rt 


ad hec, individual effort 


* Systematic Reuse 


planned , corporate-le 





45 


P Opportunistic Software Reuse 
(Software Salvage) 
* Individual effort, happens by chance, 
usually without tool support 


design svete specify 


wchitecture 


outline eystem 
re queremients component 


‘ 
incorp orate earch for 
compoment reusable 


found components 


=e Software Reuse 


* Corporate level planned effort, a 


repeatable process with infrastructure 


support 


modify requirement dean evetem 


based on requirement arch@ecture 
design, and component 


reuse 


yutline system 
on components 


requirements 
awalable 


| 


retrieve, adapt and search and qualified 
megrate reusable compoment 


components found 
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Systematic vs. Opportunistic reuse 


F, 


ystematic 


Orgamzed 
* The practice of reuse 
accord to a well- 
defined, repeatable 
process 
Planned 
* The practice of reuse 
according to a long- 


term plan 


levels of reuse 
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(pportunistac 


Ad Hoe 
* The practice of reuse 
without well-defined 


process 


Unplanned 
* The practice of reuse 
in an informal way 
without any 
-wide 


reuse straiegy 





Besiivarc Reuse Timeline 


Reuse moved from programs on a small scale 


to systems on a large scale 


Oihibineseitieem etine 


* Domain-oriented reuse involves the following 
activities 


Domain analysis 
fefine application domam to be investigated 


categorize items extracted from domain 


collect representative applications from the domain 


malyze cach application from sample 


develop a analysis model for 


Reusable component development 
* design and develop software reuemble components 


Reusable component repository support 


* create and maintain reusable component reposstory 
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10 


Siratezgy Driven Reuse 


* Migrate reuse into the company’s 
business in order to 
Cut costs and improve the quality of the 
software 
Increase agility 


Create new business opportunities 


F, 


* Decrease in Cost 


enefit of Software Reuse (1/2) 


* Increased Reliability 
components already exercised in working 
systems 

* Reduced Process Risk 


less uncertainty in development costs 
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SONS NTs) Myre) tail em atoll Kiem PARA) 

* Effective Use of Specialists 
“avoid reinventing the wheel” 

* Standards Compliance 
Component interfaces will be more 
standardized 

¢ Accelerated Development 
avoid custom development and speed up 


delivery 


Potential Show Stoppers (1/2) 


* Increase development cost 
Will happen if extensive effort is required in adapting 


the reusable code 
¢ Lack of tool support 
Will be very difficult 
ynents and t 


rhe Not-Invented-Here Syndrome 
Some soltware engineers preter to rewrite 
believe that they can do 
better job 
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Potential Show Stoppers (2/2) 


* Continue investment in maintaining a 
component library 


Improper understanding of the or g needs to maintain and 


evolve the reusable component libraries 
Difficulties in finding the correct reus able 
components 

It may be very difficult to select the correct 

component for reuse because the proper functio 

of a reusable component 

environment which the component will be wor 


in 


Summary 


In this module, you learned to: 

* Define Software Reuse 

* Describe Types of Software Reuse 

* Describe Benefits and Potential Show Stoppers of 
Software Reuse 
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nd of Lesson Questions 


What can be reused? 

Name one benefit to re 

Name two potential show stoppers of reuse’ 
What as this the definition of : “use of existing 
software artifacts in the development of other 


soltware 


MODULE 3 
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{Vvavalt Upen Architecture ¢ 


> 
wre Rowece 
VaTC NCUSE 


Besson Objectives 


* The focus of this module is to present an 
overview of the DoD/DoN effort in Software 
Reuse 

* Students who successfully complete this 
ierel trem \wl | molemele) Cem ce) 

Define Naval Open Architecture 


Summarize the Software Reuse policies trom 


Department of Defense 
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OVS IPA ie eae OF. 9) 


* Open architecture is defined as 
A type of computer or software 
architecture that is considered public. 
* The opposite of closed or proprictary 
Includes both industry standard and 
privately designed architectures that are 
made public 
Allows users to see the inner workings of 


architecture, and allows for adding, 
upgrading. and swapping of components 


aval Open Architecture (NOA) (1/4) 


The Naval Open Architecture is defined as: 
A multi-faceted strategy providing a 
framework for developing joint, 
interoperable systems that adapt and 
exploit open system design principles 
and architectures. 

It is a System Reuse framework that 
includes a set of principles, processes, 
and best practices. 





54 


16 


Raval Open Architecture (NOA) (2/4) 


The goals of NOA include: 
Optimize total system performance 
Reduce difficulties in system development 
and upgrades 
Minimize total ownership costs 
Rapidly field affordable. interoperable 
systems 


Raval Open Architecture (NOA) (3/4) 


* NOA will accomplish its goals through 
More opportunities for competition 
The use of non-proprietary standards for 
internal interfaces 
Modular architectures to allow for 
affordable interoperability and to 
accommodate changing technology and 
requirements 
Software reuse 
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Raval Open Architecture (NOA) (4/4) 


* Naval Open Architecture is a business 
process renovation, not just a changing 
software development practices as in 
Open Architecture 

NOA emphasizes on the use of 
business drivers to produce better 


and less expensive software 


F, 


oD Policies on Open Architecture 


2003, DoD Directive (DoDD) 5000.1, “The 
uisition System 
Under Secretary of Defense (Acquisition 
gistics) Memorandum, “Amplifying 
Guidance Regarding Modular Open 


Systems Approach (MOSA) Implementation 
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Pion Policies on Naval Open 


Architecture (1/4) 


¢ Assistant Scoretary of the Nawy (Research, 
Development & Acquisition) (ASN [RD&A]) 


5 AUG 2004, OA Policy Statement, “Naval Open 
Architecture Scope and Responsibilities” 
* Deputy Chief of Naval Operations (OPNAV) 
(Warfare Requirements and Program) 
(N6/N7) 
Requirement for Open 


Architecture (OA) Implementation” 


Pion Policies on Naval Open 


Architecture (2/4) 


* ASWN's memo set out OA policy, established an 
OA Enterprise Team (OAET), and assigned its 
roles and responsibilities: 

Leaci the Nz Enterpnse to OA implementation 
Provide OA Systems Engineenng leadership to 
Program Executive Office's (PEOs), industry 
partners, Jomnt Organizations, Navy Warfare Centers 


and other partacipating Organizations 
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Pon Policies on Naval Open 


Architecture (3/4) 


Provide the forum and process by which cross 
lomain OA proposals and solutions are reviewed and 
approved 

versee OA implementation efforts ensuring 
standardazed and disciplined processes are utilized 
across domains 
Identify cross-domain components and 
opportunities for cost reduction and reuse 
Leverage technical, business, and organizational 


solutions from all participating communities 


Pion Policies on Naval Open 


Architecture (4/4) 


DCNO’s memo establishes OPNAV 
requirement to implement Open Architecture 
principles across the Navy Enterprise 
Bottom line is that there is a organizational 
shift to embrace open architecture and 


software reuse in Naval system acquisition 
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Summary 


In this module, you learned: 


¢ What Naval Open Architecture is 
¢ The DoD/DoN policies on Naval Open 


Avro itiicuttice 


F: 


nd of Lesson Questions 


* What as the differences between the Open 


Architecture and the Naval Open Architecture? 


What role will Software Reuse play in the 


Naval Open Architecture? 
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MODULE 4 


iOpen 
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Lesson Objectives 


¢ The focus of tl 


1is module is to present 


Principles for effective Software Reuse 


* Students who successfully complete this 
module will be able to: 


Describe Effe 


ctive Principles 


Describe Reuse Thinking 


Describe Reuse Requireme 


F. 


tfective Pi 


with reus 


iciples 


s¢ Involves designin; 


a nd CX 


¢ Effective Principles 


Software com 


unde lent 


a 


Cotmsnon Gore for 
Successful an 
fefeutiitasinee| 
assumption 


on 


uld be 


1in abstrac 


oh interface ¢ 


lies are rated applications developed arc 


d safe reuse must have a w 
lesign rationale and design 


r both the system ar 


61 


sured a 


software 
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OTSA WE Vato) ae Bele tie 


e The key difference between reuse processes 
and conventional software engineering 
processes 1s that for reuse, the customer's 
requirements are modified to take advantage of 
what ts available for reuse. 

While the customer may not get exactly what 
they want, the software should be available 
more economical and in a shorter time 


Reuse Requirements 


Must be possible to find appropriate reusable 
components. 

Reusable components should be trustworthy 
(that the component will behave as specified 
in the requirements) 

Components should have associated 
documents to help the code specialist 
understand them and adapt them to new 
application. 
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Summary 


In this module, you learned: 
* Effective Principles 
* Reuse Mindset 


* Reuse Requirements 


ss of Lesson Questions 


Desagn with reuse involves designing software around 


good and existing components 
wotleg 


c. framework 


d. architecture 


63 
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NCO) BL G08 ee 


Software Re 


Architects 
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yo 


* The focus of this module is to introduce a process 


| esson ( Ibjectives 


for implementing Software Reuse 
+ Students who successfully complete this module 


will be able to 


Understand the orgamizational and technological enablers 
Desenbe strategy to implement software reuse 
Understand the importance of reuse metncs 


Know how to use the SHARE repository 


F. 


nablers for Software Reuse 


e The first step in setting up a reuse 
program 1s to identify and develop the 
enablers for Software Reuse, which 
consists of: 

Organizational 

* culture, structure, polices 
Technological 

¢ COTS, Component-based enginee 


domain engmecring 
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ample of Organizational Enablers 


People - Must be properly motivated and given a good 
understand of reuse 


Structure = Tunctio 


Reuse | al - opportunity + ability 
Reuse Capability - ability to harness potential 


Polaces and Procedures - must foster an environment for re 


> Shi} b) ome) ad Moved iti Te) Coles (ers) Me ahi 1e) Cogs 


* Software reuse is implemented in a 
number of different ways 
Component-based Software Engineering 
(CBSE) 
Service-oriented systems 
Enterprise Application Framework (e.g 
Enterpnse Resource Planning syst ) 


Non developmental Items (NDI) 


66 


ise 
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Examples of Enabling Technology 


Reuse libraries \pplication templates 


Generators Parameterized systems 


Laneuage-based Software architectures 

c vos, “tho 

systems Software schemas 

Computer A ided l'ransiform ational 

: systems 

Software Engineering es 

tools Virtual Machines 
Enterprise Application 
Framework 


nowledge Review 


* Name two enablers for software 


m plementat Te) 8 | 
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Dirategy for adoption of reuse 


* The second step is to establish a strateg 
gain acceptance and institutionalization of 
Software Reuse. 
rhe goal is to maximize the benefits of 
software reuse, taking into consideration 

Reso urces 
Personnel 
Activities 


Desired outcomes 


xample of a strategy 


Initiate reuse program development 
Define reuse program 
3. Establish reuse adoption goals 
Analyze reuse adoption strategies 
§. Develop reuse action plan 


Implement and monitor reuse program 
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rs. mmary of Key Implementation 


Guidelines 


Ensure Organizational and Technological 
factors are supported 

Ensure you are designing for Reuse 
Document the software components 


Get certified (Collect metrics during project) 


R 


* Benchmarking 


7 ' 
hy measure reuse? 


Use for comparison purposes 
* Influencing behavior 

Provide incentives to adopt reuse 
¢ Decision-making 


Need data upon which to make informed decisions 


regarding a reuse program 
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Types of reuse metrics 


eleva metal Mer huerel ts 


* There is no one-size-fits-all set of reuse 
mectrics 
The set of metrics should address the goals and 
needs of the organization or subunit 


a2 


rhe set of metrics should address, for each 
reuse role, the data needs for decision making 
* It is possible to misuse reuse metrics 
Can over or understate benefits and costs of 


reuse 
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ine ns Six-Stage Reuse Measurement 


| a OCCSS 
Define and clarify goals 
Identify reuse questions (that relate to the 
goals ) 
Identify reuse metrics (to answer the 
questions ) 


- Think in terms of who, when, where, what, 


Fria @itent’ 
Gather reuse metrics 
Examine reuse metrics 


Act on basis of reuse metrics 


Fr. Resource for NOA 


* Software, Hardware Asset Reuse 
Enterprise (SHARE) repository 
part of the Navy’s Open Architecture (OA) 
approach to developing open, components 
that include reusable software applications 
as a core principle 
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al soltware, Hardware Asset Reuse 


Enterprise (SHARE) repository 


Provides a capability for discovering, accessing. 
sharing. managing, and sustaining reusable assets 
Consists of an asset library and a card catalog 
Currently contains only one type of software 
specific to surface ships 


No immediate access to assets in the repository 


Summary 


In this lesson, you learned; 

* describe ways to implement software reuse 

* describe and apply examples of software reuse 
applications in NOA 


¢ Introduce the SH ARE repository 
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F 


Shire Mee) MAY Keret ty om Que tery BCeynTS 
* What are some organizational enablers 


* What are some technological enables 


¢ What is does SHARE stand for 


PC ONGRI TULATIONS 


You have successfully 
completed Software Reuse in 
the Naval Open Architecture 
Continuous Learning Module 

(CLM) 
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